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ABSTRACT 

This paper presents the capabilities implemented in the 
SAX system for an efficient operations management 
during its in-flight mission. 

SAX is an Italian scientific satellite for X-ray Astronomy 
whose major mission objectives impose quite tight 
constraints on the implementation of both the space and 
ground segment. The most relevant mission 
characteristics require an operative lifetime of two years, 
performing scientific observations both in contact and in 
non-contact periods, with a low equatorial orbit 
supported by one ground station, so that only a few 
minutes of communication are available each orbit. 

This operational scenario determines the need to have a 
satellite capable of performing the scheduled mission 
automatically and reacting autonomously to contingency 
situations. 

The implementation approach of the on-board operations 
management, through which the necessary automation 
and autonomy are achieved, follows a hierarchical 
structure. 

This has been achieved adopting a distributed avionic 
architecture. Nine different on-board computers, in fact, 
constitute the on-board data management system. Each 
of them performs the local control and monitors its own 
functions whilst the system level control is performed at 
a higher level by the Data Handling Application 
software. 

The SAX on-board architecture provides the ground 
operators with different options of intervention by three 
classes of telecommands. Tire management of the scientific 
operations will be scheduled by the Operation Control Centre 
via dedicated operating plans. 

The SAX satellite flight model is presently being 
integrated at Alenia Spazio premises in Turin for a 
launch scheduled for end ’95. 

Once in orbit, the SAX satellite will be subject to 
intensive check-out activities in order to verifiy the 
required mission performances. An overview of the 
envisaged procedure and of the necessary on-ground 
activities is therefore depicted as well in this paper. 


INTRODUCTION 

The S AX satellite is part of a scientific program whose 
objective is to observe celestial X-ray sources in the 
broad energy band from 0.1 KeV to 300 KeV. The SAX 
mission has been planned to achieve a systematic, 
integrated and comprehensive exploration of galactic and 
extra-galactic sources, providing significative 
improvements for more complete and extensive studies 
in X-ray astrophysics. 

SAX is a joint program managed by the Italian Space 
Agency (AS I) and by the Netherlands Agency for 
Aerospace Programs (NIVR) coordinating the scientific 
interest of the Italian and Dutch scientific community 
and funding an international industrial team whose 
overall organization structure includes: 

• Alenia Spazio as main contractor for the Space Segment 

• Telespazio as main contractor for the Ground Segment 

• Martin Marietta - Commercial Launch Services - as 
main contractor for the Launch Vehicle 

• Italian and Dutch Scientific Institutes as Scientific 
Consultancy. 

The SAX Payload hosted on-board consists of the following 
six scientific Instruments (Ref. 1): 

• Low Energy Concentrator Spectrometer (LECS) whose 
task is to perform X-ray spectrometry/imaging in the 
0.1-10 KeV energy range 

• Medium Energy Concentrator Spectrometer (MECS) 
whose task is to perform X-ray spectrometry/imaging in 
the 1-10 KeV energy range 

• High Pressure Gas Scintillation Proportional Counter 
(HP-GSPC) whose task is to perform X-ray 
spectrometry in the 3-120 KeV energy range 

• Phoswich Detector System (PDS) whose task is to 
perform X-ray spectrometry in the 15-300 KeV energy 
range and gamma-ray burst monitoring in the 60-600 
Kev energy range 

• Two Wide Field Cameras (WFCs) whose task is to 
perform X-ray spectrometry/ imaging in the 2-30 KeV 
energy range. 
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Fig. 1 - Satellite Overall Configuration 


The WFCs are mounted along the +Y and -Y satellite 
axes, allowing an observation of a wide sky portion, 
whereas all the other Narrow Field Instruments are 
aligned along with the +Z axis. Fig. 1 illustrates the 
satellite overall configuration. 

The SAX pointing capability ensures a target 
measurement accuracy of 1 arcmin and a pointing of 3 
arcmin for a maximum of 10 5 seconds, i.e., one day. 

All the project design has been developed to cope with a 
mission of at least two years preceeded by a 
commissioning phase period, estimated to extend for 
about eight weeks. 

The satellite is currently in a very advanced C/D phase. 
The Flight Model is under integration as the last step of 
a system integration and test campaign involving the 
developing of a Structure Model, an Engineering Model, 
and a Software Verification Facility. The launch will 
take place by end ’95 with an Atlas Centaur vehicle. The 
SAX Ground Station will be located in Singapore and 
will be connected via Intelsat to the SAX Operation 
Control Center and the Scientific Data Center, both 
located in Rome. 

MISSION CHARACTERISTICS 

The major constraint entailed by the scientific objectives 
requires a satellite orbit such that the background particle 
radiation for X-ray detection be very low and the effects 
of radiation from the South Atlantic Anomaly region be 
reduced. This leads to the choice of a circular low Earth 
orbit at a 600 Km altitude - Begin of Life (450 End of 
Life) - and an inclination of about 4\ The orbit period is 
thus of 97 minutes with an altemance of 60 minutes of 
sunlight and 37 minutes of eclipse. 


One single ground station, located near the equator, will 
support the mission offering satellite visibility each orbit The 
coverage period is anyway no longer than 1 1 minutes so that 
about 90% of orbital life is out of visibility. 

The pointing domain is limited by the allowed sun 
incident angle range on the satellite solar array surface. 
A maximum of 30° (with occasional excursions to 45°) 
inclination is allowed with respect to the sun direction to 
ensure a proper battery charge. This implies a pointing 
domain for the Narrow Field Instruments limited within 
a band in the sky 60° wide available for observation each 
orbit (except some possible occultations by celestial 
bodies). In a one year period, the whole sky will be 
observable for a scientific activity that can be estimated 
as performing between 2000 and 3000 independent 
observations (Ref. 2). 

THE SYSTEM ARCHITECTURE 

The above introduced operational scenario determines 
the need to have implemented on-board the capability of 
supporting, in an autonomous way, the execution of 
on-ground pre-defined mission plans. That also requires 
the on-board architecture to manage the nominal 
activities as well as the pre-conceived anomalies, in all 
the mission phases, taking into particular account that 
most of the mission is out of the ground coverage. 

The implementation approach of the required operation 
management is based on an avionic architecture which 
makes extensive use of a distributed on-board 
intelligence (Ref. 3). Nine on-board intelligent terminals 
constitute the SAX system architecture as shown in Fig. 
2 (see following page). 

Each of them performs the autonomous control of the 
relevant subsystem (S/S) local functions including the 
surveillance of its health status. The control of the system 
overall activity is assigned to a higher hierarchical level and 
is implemented in a Central Terminal Unit (CTU). The CTU 
is devoted to coordinating and controlling the Data 
Management and Communication System as well as to 
managing the system nominal operations and to undertaking 
the system level recovery actions. A set of non-intelligent 
subsystems, including the Telemetry Tracking & Command 
S/S, the Reaction Control S/S and the Electrical Power S/S 
are placed under the direct control of the CTU via serial lines 
through a Remote Terminal Unit. 

The interprocess communication is based on the ESA 
standard serial digital bus arbitrated by the CTU and 
composed of: 

• Interrogation Bus for CTU to local terminals 
interrogations 

• Response bus for local terminals to CTU transmission of 
Housekeeping Data (HKD) 

• Block Transfer Bus for Scientific Instruments to CTU 
transmission of Scientific Data. 
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Fig. 2 - System Architecture 


The data communication protocol is designed to ensure a 
collection of about 16 kbit/sec of HKD from the satellite 
subsystems and science instruments and up to 100 
kbit/sec of scientific data. Two different formats of HKD 
can also be selected: one essential format including a 
basic set of SAX HKD, one intensive format including 
some extra information on hot redundant units and Data 
Handling traced operations. All the data gathered in 
non-visibility are temporarily stored on a dedicated tape 
recorder, with a capacity of 510 Mbits, until requested to 
be dumped to ground during the coverage periods. Two 
channels are implemented to dump to ground the satellite 
telemetry in High Bit Rate mode: 

* channel "I" for dumping the real-time collected 
telemetry at 131 kbps 

* channel "Q" for dumping the tape recorded data at 917 
Kbps. 

A 16 Kbps link is also available to implement a Low Bit 
Rate transmission mode. 

The telecommand bit rate allows an uploading of 2 
Kbps, that is about 20 frame instructions/sec. 


ON-BOARD REDUNDANCY CONCEPT 

The SAX mission characteristics have led to a system 
design with a high degree of reliability to cope with so 
long an autonomous lifetime. 

All the spacecraft S/Ss are designed to be single failure 
tolerant whereas the Scientific Instruments implement 
redundancy only at interface level. Critical on-board 
items (e.g. receivers, decoders, gyroscopes, power units, 
protected memory) all operate in hot redundancy. In this 
context single spacecraft unit malfunction does not affect 
the nominal mission performance. 

The intelligent subsystems - i.e., On-Board Data 
Handling (OBDH), Attitude and Orbit Control S/S 
(AOCS), Thermal Control S/S (TCS) - are based on a 
fully redundant architecture. Each of their unit classes 
includes one redundant item so that one fatal failure can 
be recovered by properly activating this redundancy. 

The Scientific Instruments, not having implemented any 
internal redundancy, perform only a reduced Failure 
Detection and Isolation function for specific problems. 
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All the on-board computers maintain at least the software 
(SW) basic functions stored in Programmable Read Only 
Memories so that any reset/switch-over cannot cause the 
loss of the code, as it is downloaded from PROM to 
RAM any time a (re)-initialization takes place. 
Embedded circuitry for error detection and correction of 
corrupted memory cells by single event upset as well as 
a watch-dog circuitry for autonomous reconfigurations 
are provided in all the intelligent subsystems. 

All the data considered critical for the proper on-board 
autonomous maintenance of the mission, in any nominal 
or contingency situation, are dynamically maintained in 
dedicated Protected Memory Areas. According to the 
relevant OBDH and AOCS performed control, this data 
set is so classified and grouped: 

• OBDH Application SW (A/SW) vital data, including the 
Solar Array deployment status, the launcher separation 
status, the system and some critical S/S items active 
configuration (e.g. transmitters, battery discharge 
regulators, reaction control S/S branches, etc.) 

• OBDH Basic SW (B/SW) vital data, including the 
launcher separation status, the OBDH active unit 
configuration, the redundancy management data 

• Time Tagged commands to be scheduled at their own 
pre-set time 

• Real Time commands to be executed at CTU 
switch-over 

• AOCS S/S active configuration and launcher separation 
status, maintained in dedicated AOCS solid state latches. 

The failure management of non-intelligent S/Ss is 
performed at centralized level by the OBDH A/SW. 
Some exceptions deviate from this general approach: 

• Power S/S performs the failure management for its own 
units; 

• the hydrazine flow control valves are under control of 
the AOCS when it makes use of thrusters; 

and these are driven by time intervention constraints. 

MISSION PHASES 

The SAX mission can be divided into four overall 
mission phases. 

• Launch Phase 

LP begins at spacecraft power-on just before vehicle 
lift-off and extends to the physical separation between 
the launcher and SAX. In this phase the S/Ss are 
initialized and perform a continuous control of the 
powered units. No attitude manoeuvre is of course 
executed as the AOCS is in its initialization mode 
until the separation. The on-board produced data are 
stored on the tape recorder, just after the launch 
vibrations terminate, for later transmission to ground. 


• Commissioning Phase 

This begins at the SAX-launcher separation and 
extends to the completion of all initial in-orbit tests 
and calibrations. As a first step, it consists of an Early 
Orbit Phase which comprises a short post separation 
coast period, a reduction of any residual S/L body 
rates and a subsequent Sun/Earth acquisition period. 
Upon successful completion of these activities the 
deployment of the Solar Arrays is autonomously 
operated. 

The commissioning of the satellite shall proceed with 
an initial health check-out continuing with systematic 
functional checks of all the subsystem nominal 
functionalities. 

The Scientific Instrument activation and functional 
verification shall be operated as a last step. Some 
overlaps between the two shall be necessary for a 
complementary check-out of both the spacecraft and 
the Scientific Instruments. All these operations shall 
be initiated by ground and supported by the on-board 
SW tasks. 

• Operational Orbit Phase 

This phase covers the period of the satellite’s useful 
scientific lifetime. It shall be nominally two years and 
shall be characterized by routine scientific operations. 
The satellite design shall, anyway, allow an extention 
of the mission beyond the nominal period up to a total 
four years lifetime. 

• End of Life Phase 

This phase covers the period when SAX is no longer 
capable of producing useful scientific information due 
to either component degradation or altitude decay. 

SATELLITE MODES 

The system mode design has been structured to cope 
with all the SAX mission phases (Ref. 4). The satellite 
modes - implemented with a direct correspondence with 
the AOCS modes - drive all the on-board autonomous 
operations. Their transitions can be initiated either upon 
ground commands or at the occurrence of automatic 
fallbacks caused by system autonomous emergency 
re-configurations. The SAX mode transitions diagram is 
reported in Fig. 3 (see following page). 

The mission/science support modes are the principle 
configuration to support the scientific activity. The 
default/safety modes correspond to the main operative 
configurations to be assumed in case of interim science 
activity or on-board emergency. Two further modes 
support special operations during the launch phase and 
during the orbit raising manoeuvre - if ever needed. 

• Satellite Launch Mode (SLM) 

Routine operations are performed to ensure an health 
satellite status ready to operate just after the 
SAX-launcher separation. 
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MISSION/SCIENCE MODES 


Fig. 3 - Mode Transition Diagram 


The produced telemetry is recorded only after the 
vibration level is reduced - the activation of the 
on-board tape recorder is made by a time tagged 
command. 

• Satellite Sun Earth Pointing Mode (SSEPM) 

This mode is automatically entered either at 
SAX-launcher separation or as fail-back from the other 
Nominal Satellite modes. Purpose of this mode is to 
maintain the satellite in a 3-axis stabilized attitude 
optimizing the sun incidence on the Solar Arrays. As 
this mode is entered from the separation, it has to 
accomplish a very critical sequence of operations most 
of them to be performed autonomously since they are 
out of the ground coverage. The major operations are 
initiated by the OBDH and AOCS software that have to 
coordinate the safe attitude acquisition with the Solar 
Arrays deployment. Trigger of these operations is the 
SAX-launcher separation, detected by a dedicated fully 
redundant hardware circuitry and sent to both the S/Ss. 


• Satellite Interim Science Mode (SISM) 

This mode configures the SAX satellite in a accurate 
three-axes stabilized attitude making use of one star 
tracker, besides all the other used sensors. This fine 
pointing helps in keeping a default attitude (e.g. 
Polaris pointing) and in fastening attitude transitions 
to scientific modes. 

• Satellite Nominal Science Mode (SNSM) 

The satellite remains in this mode while operating the 
planned scientific observations. A very fine pointing 
is made by use of the AOCS star trackers. All the 
scientific data produced by the Scientific Instruments 
are collected by the OBDH according to a dedicated 
polling algorithm. 

• Satellite Slow Scan Mode (SSSM) 

This mode will mainly be used to perform calibrations 
of Non-Imaging Scientific Instruments by performing 
sequential slews across a known target. 
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• Satellite Delta-V Mode (SDVM) 

This mode is designed to cope with the altitude decay, 
raising the satellite orbit in the case the SAX altitude 
decreases below the 450 Km. 

• Satellite Safe Mode (SSM) 

This mode is entered upon detection of specific 
system-level failures. A safe attitude is then maintained 
by the AOCS pointing the Solar Array surfaces toward 
the sun and aligning the satellite with the earth magnetic 
field. 

OPERATION MANAGEMENT STRUCTURE 

The management of the SAX system operating modes is 
implemented by a multi-level hierarchical structure (Ref. 
5) involving, in increasing priority: 

• the S/L Subsystems and Scientific Instruments 

• the OBDH Application Software 

• the Ground Operation Control Centre. 

To the upper levels is assigned the task of initiating the 
scheduling of system level functions as well as the 
capability of controlling and overriding the lower level 
decisions. On the other hand, the main nominal 
operations autonomously performed at local level allow 
the proper control and setting of the relevant S/S. In 
particular, the intelligent terminals and Scientific 
Instruments are designed to be fully autonomous in 
performing their relevant tasks so that they can in 
principle continue operating consistently without any 
external intervention. Few inputs are, in fact, needed 
only for tuning their performances and their 
configurations with respect to either the system 
configuration or the current mission characteristics. 

Each of the intelligent subsystems also performs a 
Failure Detection, Isolation and Recovery (FDIR) 
management on its own, keeping under control the 
configuration, functioning and health status of all its 
relevant units. In the case a malfunction is detected, the 
fault unit can be substituted by the redundant one. If the 
main S/S computer is affected an automatic switch-over 
takes place. The redundant intelligent unit will then be 
initialized assuming a safe mode of functioning. 

The Scientific Instruments, not having a redundant 
architecture, adopt a self disabling policy, in particular, 
against a too high level of particle radiation able to 
damage the instrument itself. 

Purpose of the OBDH A/SW is to keep under control all 
the subsystem level operations; that implies a system 
supervision to ensure the proper nominal/safety satellite 
consistency. What has been assigned to the A/SW is the 
role of the on-board coordinator of all the major flight 
operations between themselves and with respect to the 
ground scheduled plans. 


It is in particular devoted to: 

* perform Solar Array deployment following the launcher 
separation and sun/earth acquisition 

* inform the AOCS of the new inertia matrix to be used 
after the Solar Array deployment 

* support the distribution and enabling of operating plans 
to the AOCS and Scientific Instruments 

* support the Ground-to-Satellite link acquisition and 
downlink telemetry operations 

* enable/disable power resources to the non-essential 
satellite loads, i.e., Scientific Instruments, Reaction 
Control S/S, thermal control heaters 

* perform the deployment of the Scientific Instrument 
baffles 

* manage satellite mode transitions as a consequence of 

Intelligent S/S switch-over 

AOCS mode fallbacks 

Power S/S protection triggering 

Scientific Instrument particle over-radiation detection. 

All the A/SW operations are coordinated and 
synchronized by the proper activation of dedicated 
pre-defined command sequences and command loops. 
These can be activated either by ground or autonomously 
to accomplish the above introduced operation set. The 
OBDH A/SW core is based on three principal modules 
acting as the kernel of the A/SW architecture, as 
illustrated in Fig. 4 (following page). 

* The Mission Manager: it monitors the mode transitions 
of all the subsystems and instruments which require 
corrective operations. It is based on a mode transition 
table indicating all the actions to be undertaken at the 
occurrence of S/S mode transitions. It in particular 
specifies the safe configurations to be adopted in case of 
some critical mode fail-backs. It also drives the 
enabling/disabling statuses to be applied to the A/SW 
controls, as a function of the satellite mode 
configuration. 

* The Fault Manager: it cyclically checks a pre-defined 
sub-set of the on-board produced monitors to undertake 
subsequent actions to isolate and/or recover the related 
problems. The data set includes all the mission critical 
on-board items, provided on a periodic basis and kept 
under control by means of a table driven FDIR manager. 
The control is performed by periodic tasks scheduled 
every second. 

A cross-check is then made between the measured 
values and their relevant expected ranges. Any 
discrepancy activates a direct recovery action on the 
non-intelligent S/S with possible extension to a system 
reconfiguration in the case the malfunction can severely 
affect the system performance. 
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Fig. 4 - OBDH Application Software Architecture 


• The Telecommand Server: it manages the ground 
initiated operations distributing and verifying the 
command execution. 

It furthermore applies a consistency checks on the 
ground up-loaded requests against the current system 
configuration. In the case a conflict is detected a report 
is provided in the A/SW telemetry but no action is 
undertaken until an explicit ground override is operated. 

The top level of the SAX operations is, of course, a 
ground task. It is responsible for acting on the satellite 
configuration in order to set it up properly to accomplish 
the planned scientific observations. It has therefore to 
operate on both the spacecraft and the Scientific 
Instruments. Besides, routine maintenance operations 
have to be scheduled to cope with the orbit and mission 
events/constraints. 

Some of the more frequent operations are anyway related 
to the orbit contact management whose ground 
intervention extends to: 


* linking acquisition via the proper activation of the 
transmitter linked to the ground facing antenna. This is 
done by a time tagged telecommand acting on a 
dedicated A/SW command sequence which is devoted to 
verifying the correct functioning of the on-boaixl link 
chain 

* enabling the telemetry transmission to ground once the 
down-link carrier is obtained. This concerns the 
real-time telemetry and, on request, the on-tape data 
stored in the non-coverage period 

* restoring the on-board data recording and termination of 
the link before the end of the contact period 

* command the issuing of the on-board time samples for 
on-ground data correlation 

* managing the antennae switch-over as the coverage 
concerning the facing antenna is going to end. Note that 
two hemispherical antennae are implemented on SAX in 
order to cover the whole space around the satellite. 

Less frequent operations are related to scientific 
observation management. That involves: 

* changes of the satellite attitude via dedicated AOCS 
Operating Plans 

* changes of allowed pointing domains 

* changes of Scientific Instrument operating modes 

* Scientific Instrument configuration management, in 
particular at any entry/exit of the South Atlantic 
Anomaly. 

Other infrequent operations are related to performance or 
maintenance aspects. In this context, the ground control 
centre shall periodically monitor the satellite dumped 
telemetry to keep under control the actual on-board 
configuration. It can therefore intervene for recovering 
any on-board assumed safe mode or, simply, for tuning 
some control parameters such as, for example, battery 
End Of Charge and/or End Of Discharge levels, thermal 
loop thresholds and/or enabling/disabling flags, sun 
vector and attitude quaternion values, etc.. 

GROUND COMMANDING CAPABILITY 

The ground commanding capability is driven by three 
major parameters: 

• the visibility period 

• the up-link characteristics 

• the on-board command management design & 
operations. 

The major constraint on the commanding capability 
comes from the very limited visibility window This 
requires the Operation Control Centre to prepare a 
well-defined timeline for a long period, e.g. one week - 
corresponding to about one hundred passages, operating 
in the interin of two passages just to analyze the dumped 
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AB * OBDH A/SW or B/SW routing flag 
TT ■ Time Tag flag 
SO * switchover flag 

Fig. 5 - Block Command Structure 


telemetry and to react to any anomaly detected. All the 
commands necessary for operating the satellite both in 
and out of visibility must be up-loaded during the 
contact period. 

The up-link characteristics are based on the ESA PCM 
Telecommand Standard. It allows the transmission of 
2000 bps, that is - as the ESA standard telecommand 
frame is 96 bits long - a bit more than 20 frames/second. 
The minimum instruction can be based on a single frame 
structure. In the case a complex command is needed, a 
mutiframe message - constituting a block command - can 
be up-loaded. The block command structure used on 
SAX is shown in Fig. 5. 

Based on the above mentioned standard, the on-board 
design provides ground with three different options of 
intervention. Three classes of commands are, in fact, 
made available and properly managed on board. 

• Single frame commands that can be used to up-load high 
priority command whose purpose is to operate on a 
critical subset of the satellite hardware devices. This type 
of commands by-passes any on-board SW control and, 
via the decoder, directly acts on the end items. This class 
is thus useful as a back-up in case of an emergency. 
Typical applications are switching operations involving, 
for example, unit selection and separation event override 
command to AOCS. 

• Single frame commands that can be used to directly 
issue single instructions on the OBDH Bus to any 
terminal. This class might be used only in the case of 
OBDH B/SW bus management malfunction since they 
by-pass the OBDH B/SW control. Care might therefore 
be taken because such asynchronous instructions can 
affect the proper OBDH Bus protocol functioning. 


• Block commands that represent the nominal way of 
commanding. Their structure can be flexibly filled in so 
that they can contain either one multi-parameter 
command or a set of single instructions or one operating 
plan. Their routing is performed by the OBDH B/SW 
according to the destination field content. Other 
syntactic/semantic information is contained in the block 
header for on-board verification and execution, i.e., 
begin pattern, destination, name and length. 

What is particularly important to emphasize is the 
on-board capability of managing the block commands as 
delayed commands. By means of a dedicated flag, 
ground can, in fact, impose their execution at the time 
specified in the relevant tag field. A queue of one 
hundred time tagged commands is dedicated in the 
OBDH protected memory area. - an estimation of about 
60 block commands, as a maximum, has been evaluated 
as necessary each orbit for nominal spacecraft and 
Scientific Instrument operations. It is worthwhile noting 
that a dedicated flag is also present in the block structure 
indicating whether the command has to be deleted in 
case of CTU switch-over. Since a system reconfiguration 
takes place at the CTU switch-over, this option is quite 
useful to avoid any unwanted override unless not 
explicitly authorized by ground. The mission critical 
commands, e.g. Transmitter ON command, should, 
anyway, always remain in the queue until their 
scheduling time elapses. 

Within these commanding possibilities ground can 
address specific requests to any on-board subsystem 
coordinating the mission operations both in and out of 
visibility. 

One of the major aspects offered by the OBDH A/SW 
design is the capability of modifying the OBDH A/SW 
control, devoted to the system operations, by means of 
simple enabling/disabling commands. As the most 
important A/SW functions are implemented by a table 
driven mechanism, a flag has been associated to each of 
the table entries. 

The relevant control can be made active or inhibited by 
setting the proper value of these flags. An easy updating 
of the table elements, used as comparison for activating 
autonomous recovery actions, can be, as well, easily 
done by mean of dedicated commands. 

One of the more powerful features that are made 
available for emergency ground intervention is specific 
command to the OBDH operating system. The OBDH 
SW - in particular the A/SW - is based on a very 
modular architecture so that each command loop and 
sequence has been implemented as a stand alone task. 
Therefore, proper acting on the operating system 
primitives can modify the task scheduling mechanism. 
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In particular, the following main interventions can be 
run-time commanded: 

* change the task priority 

* init/start/stop tasks 

* send/receive messages on mailboxes. 

This mainly allows the introduction of a new task 
implementing new functionalities or replacing the current 
ones. 

The lowest level of possible intervention by ground is 
the patching of the Intelligent Terminal software. It can 
be accomplished through the OBDH support which 
either autonomously executes the patch command on 
itself, if so addressed, or routes the new data/instructions 
towards the relevant Intelligent Terminal via the OBDH 
Bus protocol. The same can be done by directly sending 
patching commands to the AOCS and the LECS which 
implement the capabilities of executing the patching by 
themselves. This avoids putting the microprocessors in 
wait state until the patch is terminated. 

Both the interventions on the operating system and the 
code have anyway to be planned very carefully with the 
support of a Software Maintenance Facility whose team 
shall have a very thorough expertise. 

As far as the telemetry commanding capability is 
concerned, two major features are provided on SAX. 

The first one concerns the housekeeping data 
transmission to ground whose format can be selected 
between two: 

* one essential format corresponding to the produced data 
set from all the subsystems 

* one intensive format that, besides the previous set, 
includes extra data packets from the hot redundant 
battery control unit and the B/SW tracing process. 

The second is devoted to driving the scientific data 
collection algorithm. The algorithm, once the scientific 
activity is enabled, is executed every second, polling the 
six scientific instruments to get the number of ready 
scientific packets. The share of the successive scheduled 
acquisitions between the instruments is based on two 
ground configurable allocation tables, each of their 
entries indicating one, out of six, instrument address. 
Adjustment of the content of the two tables can be done 
by ground according to each Scientific Instrument data 
production forecast. Two dedicated commands are 
available for this purpose. 

Last but not least, extra data can be required by ground, 
dumping both the code and the data segments of each 
Intelligent Terminal for diagnostic purposes. That in 
particular allows to obtain some memory areas of the 
Intelligent Terminals devoted to storing history or trace 
records not included in the periodic provided telemetry. 


OPERATING PLANS 

Setting the AOCS and Scientific Instrument 
configurations and modes usually requires many 
commands. This can overload both the time tagged 
command queue and the related scanning process. A 
solution to this potential problem has been found in 
grouping a consistent set of commands into only one 
Operating Plan. 

Two types of plans are, in particular, implemented on 
SAX: 


• AOP - Attitude Operating Plans - devoted to 
commanding the mode transitions of the AOCS and to 
controlling the attitude manoeuvres within the fine 
pointing modes 

• POP - Payload Operating Plans - devoted to setting-up 
the instrument configuration and the data output formats 
for the required scientific performance. 

These plans can be up-loaded encapsulated into one 
command block and then stored in a dedicated Parcking 
Memory Area. Their activation is requested by ground 
via the associated Transfer and Enable Commands, 
either in real-time or delayed with proper time tags. The 
actual execution, by the destination terminal, shall follow 
the correct reception and validation of the incoming 
Operating Plan only once the Enable command is 
received. Supervision of the whole consistency of this 
transfer/enabling process is centralized and 
autonomously made by the OBDH A/SW. It is, in fact, 
in charge, if enabled, of filtering the Transfer and Enable 
commands if not consistent with the satellite 
mode/configuration, e.g. in the case of Safe Mode 
fall-back. 

As far as the safe AOCS modes are concerned no AOP 
are, anyway, needed since the related attitudes are 
autonomously acquired and indefinitely kept. 

COMMISSIONING CHECK-OUT 

The in-flight verification of SAX will be performed in a 
designated eigth week Commissioning Phase following 
its launch and separation from the launch vehicle. 

The purpose of the Commissioning Phase is to validate 
the functionality and operability of the satellite and give 
the go-ahead to the scientific mission. The relevant 
check-out activity is comprised of two principal 
sub-phases. 

Phase I involves the basic functional/ perfoimance 
verification of each of the spacecraft subsystems. 

Phase II complements Phase I by extending the verification 
to all the Scientific Instruments and completing the 
verification of the fully active system configuration. 
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A summary of the planned activities includes: 

• Mode Functionality Verification 

All nominal modes shall be verified for functionality, 
valid telemetry parameters and expected ranges with 
respect to the inherent functions of each mode. 

• Commanded Mode Transitions 

All nominal mode transitions requiring an uplinked 
procedure from Ground will be performed and 
verified. Certain transitions will be omitted for 
specific reasons, e.g. Delta-V mode transitions. 

• Autonomous Mode Transitions 

Verifications of autonomous fall-backs will not be 
performed as they require fault conditions forced by 
ground. 

• Cyclic and Selectable Telemetry Verification 

All the cyclically generated telemetry will be verified 
for correct protocol handling, telemetry block 
structures, parameter location and consistent time and 
block counter fields. Variable telemetry activated by 
ground will be verified as well, e.g. dumped data and 
scientific packets. 

• On-board Memory Patch and Dump 

Dump operations will be required to evaluate control 
parameters not visible in regular telemetry, e.g. AOCS 
database, history areas, etc. Patches of program or 
data memories are not a nominal activity but could 
sometimes be necessary for table item updating, e.g. 
LECS Instrument. A dump should always be required 
after a patch operation. 

• Control Function Calibrations 

Calibrations or maintenance are required to optimize 
the overall performance of both the Scientific 
Instruments and the Subsystems, e.g. thermal control 
loops thresholds. Instrument digital and analogue 
discriminator levels, etc.. 

• Redundant Unit Check-out 

Under nominal operations all operative redundant 
units will be verified for correct functionalities, e.g. 
gyros, decoders, receivers, etc.. Cold redundant units 
will not be activated or verified unless necessary 
because of failures. It is considered more prudent to 
maintain a good nominal configuration rather than 
risk possible failure in activating the redundant one. 


CONCLUSIONS 

The SAX satellite is the result of a quite challenging mission 
requirement implementation. 

Once in orbit it will support the extensive activity of six 
complex Scientific Instruments performing parallel X-ray 
observations. 

The system design is based on a distributed intelligent 
architecture allocating to each of the on-board computers 
its own specific function. This has been designed to 
provide the maximum flexibility and reliability in 
autonomously executing the ground mission plans. The 
SAX implementation of the operating modes, in fact, 
allows the on-board configuration to be maintained by 
itself, supporting, at the same time, the ground required 
operations. 

To conclude, the SAX mission will not only provide the 
most up-to-date results in the field of X-ray astrophysics, 
but it will also make operative a very powerful system 
that is the product of Italian scientific satellite 
engineering. 
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